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ABSTRACT 

This paper describes an approach for obtaining direct access to the attacked squares of sliding pieces 
without resorting to rotated bitboards. The technique involves creating four hash tables using the 
built in hash arrays from an interpreted, high level language. The rank, file, and diagonal occupancy 
are first isolated by masking the desired portion of the board. The attacked squares are then directly 
retrieved from the hash tables. Maintaining incrementally updated rotated bitboards becomes unnec- 
essary as does all the updating, mapping and shifting required to access the attacked squares. Finally, 
rotated bitboard move generation speed is compared with that of the direct hash table lookup method. 

1. INTRODUCTION 

Prior to the their introduction by the Soviet chess program KAISSA in the late 1960s, bitboards were used 
in checkers playing programs as described in Samuel (1959). The elegance and performance advantages of 
bitboard-based programs attracted many chess programmers and bitboards were used by most early programs 
(Slate and Atkin (1978), Adelson-Velskii et al. (1970), and Hyatt, Gower, and Nelson (1990)). But to fully 
exploit the performance advantages of parallel, bitwise logical operations afforded by bitboards, most programs 
maintain, and incrementally update, rotated bitboards. These rotated bitboards allow for easy attack detection 
without having to loop over the squares of a particular rank, file, or diagonal as described in Heinz (1997) and 
Hyatt (1999). The file occupancy is computed by using an occupancy bitboard rotated 90 degrees and then using 
the rank attack hash tables to find the attacked squares. Once the attacked squares are known, they are mapped 
back to their original file squares for move generation. The diagonal attacks are handled similarly except that 
the rotation involved is 45 (or -45) degrees depending on which diagonal is being investigated. These rotated 
occupancy bitboards are incrementally updated after each move to avoid the performance penalty of dynamically 
recreating them from scratch at every move. 

2. DIRECT LOOKUP 

As researchers and practitioners explore Shannon type B approaches to chess programming (Shannon, 1950), 
code clarity and expressive power become important in implementing complex evaluation functions and move 
ordering algorithms. Many high level programming languages (notably Python (van Rossum, 1993)) have 
useful predefined data structures (e.g. associative arrays) which are dynamically resizable hash tables that 
resolve collisions by probing techniques. The basic lookup function used in Python is based on Algorithm 
D: Open Addressing with Double Hashing from Section 6.4 in Knuth (1998). We define four dictionaries 
that are two dimensional hash tables which the are main focus of this paper: rank_attacks, file.attacks. 
diag .attacks _ne, and diag .attacks _nw representing the rank, file, and two diagonal directions ("ne" repre- 
sents the northeast A1-H8 diagonals and "nw" represents the northwest A8-H1 diagonals). In order to use these 
hash tables directly, we need to also create rank, file and diagonal mask bitboards for each of the squares (e.g. 
diagjmaskjie[cA] = a2|63|c4|d5|e6|/7|gf8). These hash tables only need to be generated at startup. The ini- 
tial cost of calculating these tables can be avoided altogether if the table values are stored in a file and simply 
retrieved. 
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Figure 1: C4 White Bishop Attacks and Attacked Squares Bitboard 

The first dimension represents the location of the attacking (sliding) piece and the second dimension represents 
the occupancy of the particular rank, file, or diagonal. The first dimension has 64 possible values and the second 
has 256 possible values (except for the diagonals with fewer then eight squares). While the sizes of these hash 
tables are small, the actual values are fairly large (up to 2 64 — 1). The reason for this is that these hash tables are 
called directly from the bitboard values retrieved from the chess board. In Figure 1, the squares attacked by the 
bishop at square c4 would ideally be found by simply calculating the occupancy of the two diagonals intersecting 
at the square c4 and then performing a logical OR of the attacked squares provided by direct lookup of the two 
diagonal hash tables and then removing squares occupied by friendly pieces. The techniques described in this 
paper provide the attacked squares that are both unoccupied and occupied. These same attack vectors are also 
used in evaluation functions that require attacks from a certain square as well as attacks on a certain square. 

2.1 Rank Attacks 

The rank attack hash array can best be understood by starting with the first rank. (Note: in the subsequent 
listings, the convenience variables for each square are created so that hl=l, al=128, h8=72057594037927936, 
a8=9223372036854775808, etc.) The rank attack for the first rank is given by the following: 

rank-attacks rankl (Pranki , Orankt ) = #i + Bj 

where Prank! 1S the position of the sliding piece (rook or queen) on the first rank, o ran ) tl is the occupancy value 
for the first rank, I is the first occupied square to the left of the sliding piece, and r is the first occupied square to 
the right of the sliding piece. And Bi is the value given by 

g _ j 2 l , if 1 exists at i th bit of o ran k 1 ; 
1 \ 0, otherwise. 

Then finally, to find the rank attacks at the i th rank, we simply move this first rank value "up" in rank by 
multiplying by 256 rank ~ 1 since moving a piece up one rank on the chessboard is the same as left shifting a 
binary number by 8 or multiplying by 2 8 . 

rank-attackSrankiiPranki 7 °ranki) = r<m k-(lttclcks ran i. 1 {Prank 1 7 ran k 1 ) ■ 256 
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where the piece position index and occupancy index at rank i are also multiplied by the same value as the attack 

Pranki — Pranki ' 256 
Oranki — ®rank\ ' 256 

An implementation of this is shown in Listing 1. Here, the function's outer loop (variable i in line 3) iterates 
the attacking piece over the squares of the first rank beginning with square hi. The rank_attacks hash table is 
initialized in line 2 and in lines 4 and 5. The second loop iterates over the possible 256 occupancy values for a 
rank (line 6). After some initialization, the function moves one square to the right of the attacking piece, adding 
the value to the hash table. If the square is occupied, there is a piece that will block further movement in this 
direction and so we break out of this right side summation. This process is repeated for the left side of the 
attacking square (lines 12-15). Finally, when the rank.attack hash table is complete for the particular attacking 
square, the function shifts the values for each respective rank for the remaining ranks (lines 16-21). Note that 
this hash table includes blocking squares that are occupied by both enemy and friendly pieces. The friendly piece 
occupancy will need to be removed before assembling the legal moves. 

Listing 1: Rank Attack Lookup Table 

1 def get_rank_attacks (): 



2 rank_attacks = {} 

3 for i in range(8): 

4 for r in range(8): 

5 rank_attacks [1 « (i + (r * 8))] = {} 

6 for j in range(256): 

7 rank_attacks [1 « i][j] = 

8 for right in range(i— 1, -1, -1): 

9 rank_attacks [1 « i][j] |= l«right # save it 

10 if ( ( 1 « right) & j != 0): # non empty space 

11 break 

12 for left in range ( i + 1 ,8): 

13 rank.attacks [1 « i][j] |= 1 « left # save it 

14 if ((1 « left) & j != 0): # non empty space 

15 break 

16 for rank in range(l,8): 

17 x = 1 « ( i +(rank *8)) 

18 y = j « (rank*8) 

19 value = rank_attacks[l « i ] [ j ] 

20 newvalue = value « (rank*8) 

21 rank_attacks [x ] [ y ] = newvalue 
22 

23 return ( rank_attacks ) 



2.2 File Attacks 

The file attacks hash table uses the values obtained in the rank attack table on the first rank and performs a 90 
degree rotation. In the approach shown here, the 8th file file-attacks fu es hash table is obtained by converting the 
rank 1 rank^attacksrank! table to base 256. The bitboard position of the sliding piece as well as the occupancy 
are also converted in a similar fashion. 

8 

file-attacks faeg (p fUeg , o f iles ) = ^B t - 256 4 

i=l 

where Bi is the i th bit of the rank 1 rank_attacks table (with hi being the LSB and al being the MSB) and 

P files = Pranki ' 256 (9 ~ /) 
8 

Of ties = X! Ofila ' 256 ' 
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Listing 2: File Attack Lookup Table 

1 def g e t _f i 1 e _ a 1 1 ack s (): 

2 # this routing assumes that the rank_attacks have already 

3 # been calculated. 

4 file_attacks = {} 

5 for i in range(64): 

6 r = rank[l « i] - 1 

7 mirror_i = r an k _ t o _f i 1 e ( ( 1 « i) » (8*r)) « r 

8 f i 1 e _att ac ks [ mirror _i ] = {} 

9 for j in range(256): 

10 mirror_j = r ank _t o _f i 1 e ( j ) « r 

11 value = rank.attacks [1 « i][j « (8*r)] 

12 lower_value = value » (8*r) 

13 file.value = r a n k _t o _f i 1 e ( lower .value ) 

14 final.value = file.value « r 

15 file .attacks [ mirror.i ][ mirror.j ] = final.value 

16 return ( file.attacks ) 



where / is the actual file number of the position square Pfu es on the first rank and Ofu £i is the i th bit of the 
occupancy on the first rank. 

The implementation of this is shown in Listing 2 and uses the rank_attacks hash table found earlier (line 1 1). This 
function has an outer loop that ranges over the 64 squares, for the attacking piece, and for each of these, an inner 
loop that loops over all the occupancy values. In line 7, we find the symmetric square value if reflected across the 
A8-H1 diagonal (e.g. gl is reflected across the line of symmetry and onto square h2, fl to h3, etc.). In this way, 
the position values are flipped or "rotated" 90 degrees and the occupancy values are also rotated in line 10. The 
function rank_to_file() performs this rotation by converting the number to base two and then to base 256. In line 
1 1, the attacked squares that were calculated in Listing 1 are also rotated. 



2.3 Diagonal Attacks 

The attacked squares along the diagonals are a little more complex to calculate using the base conversion tech- 
nique used on the file_attacks. A more direct approach like the one used to find the rank_attacks, involving shifting 
and adding, is used. The diagonal hash tables can be found by summing over the squares up to and including the 
blocking square. The A1-H8 diagonal can be found 



p— 1 r 

diag .attacks jne{p, o) = ^ Bi + ^ B t 

i=l i=p+l 

where p is the position of the sliding piece (bishop or queen), o is the occupancy value for the diagonal, I is the 
first occupied square along the diagonal to the left of the sliding piece, and r is the first occupied square along 
the diagonal to the right of the sliding piece. Bi is the value of the number if the i th bit is set 

B = f2% if 1 exists at i th bit of o; 
* \ 0, otherwise. 

The other diagonal hash table (for the A8-H1 direction) is not shown but has a similar structure. 

An implementation of this is shown in Listing 3. Each diagonal is looped over (line 5) for the outer loop and the 
attacking piece is moved along the diagonal for the inner loop (line 7). For each position of the attacking piece, 
all of the possible occupancies are generated (line 10) and the two inner loops, one for the right side (lines 12-15) 
and one for the left side (lines 16-19), are used to accumulate open squares until blocking bits are encountered. 
The function completes by converting the occupancy value to a bitboard number along the diagonal. Not shown is 
a hash table called bin2index used to convert bitboard values to square index values (e.g. al— >7). The function is 
called with a list of lists of the values of the diagonals. For the A1-H8 direction (also referred to as the "northeast" 
or ne direction), the diagonal values are shown in lines 28-42 and for the A8-H1 diagonals, the diagonal values 
passed into the function are shown in lines 46-60. 
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Listing 3: Generalized Attack Lookup Table 



1 def get_attacks ( s q u ar e _1 i s t =None ) : 

2 attack_table = {} 

3 attack_table[0] = {} 

4 attack.table [0] [0] = 

5 for i in range ( len ( s q u a r e _ 1 i s t ) ) : 

6 list, size = len(square_list[i]) 

7 for c urr e n t _p o s i t i on in range ( 1 i s t _ s i z e ) : 

8 current.bb = s q u ar e _ 1 i s t [ i ] [ c urr e n t _p o s i t i on ] 

9 attack_table [ current_bb ] = {} 

10 for occupation in range(l « list.size): 

11 moves = 

12 for newsquare in range ( c urr e n t _p o s i ti on + 1 , 1 i s t _ s i z e ) : 

13 moves |= s q u are _ 1 i s t [ i ][ newsquare ] 

14 if ((1 « newsquare) & occupation): 

15 break 

16 for newsquare in range ( c urrent _po s it i o n — 1 , — 1 , — 1): 

17 moves |= s q u are _1 i s t [ i ][ newsquare ] 

18 if ((1 « newsquare) & occupation): 

19 break 

20 temp.bb = 

21 While (occupation): 

22 lowest = lsb(occupation) 

23 temp_bb |= sq uare _li st [ i ][ bin2index [ lowest ] ] 

24 occupation = c 1 e ar _ 1 s b ( occupation ) 

25 return ( attack.table ) 
26 

27 def get _diag .attacks _ne (): 

28 diag_values = [[hi ] , 

29 [h2,gl], 

30 [h3,g2,fl], 

31 [h4 ,g3 , 12 , el ] , 

32 [h5,g4,f3 ,e2,dl] , 

33 [h6 ,g5 ,f4 ,e3 , d2 ,cl ] , 

34 [h7,g6,f5 ,e4 ,d3 ,c2 ,bl ] , 

35 [h8 ,g7 ,f6 ,e5 , d4 , c3 , b2 ,al ] , 

36 [g8 ,f7 ,e6 , d5 , c4 , b3 , a2 ] , 

37 [f8 ,e7 ,d6,c5 ,b4,a3] , 

38 [e8 ,d7 ,c6 ,b5 , a4] , 

39 [d8 ,c7 ,b6 , a5 ] , 

40 [c8,b7,a6], 

41 [b8,a7], 

42 [a8]] 

43 return (get_diag_attacks(diag_values)) 
44 

45 def ge t _di ag s .attacks _nw (): 

46 diag_values = [[al], 

47 [bl,a2], 

48 [cl,b2,a3], 

49 [dl ,c2 ,b3 , a4 ] , 

50 [el ,d2,c3 ,b4,a5] , 

51 [fl ,e2,d3,c4,b5,a6] , 

52 [gl J2 ,e3 ,d4,c5 , b6 , a7 ] , 

53 [hi ,g2 ,f3 ,e4 , d5 , c6 , b7 , a8 ] , 

54 [h2,g3,f4 ,e5 ,d6,c7,b8] , 

55 [h3,g4,f5 ,e6,d7,c8] , 

56 [h4 ,g5 , f6 ,e7 ,d8] , 

57 [h5,g6,f7 ,e8] , 

58 [h6,g7,f8], 

59 [h7,g8], 

60 [h8]] 

61 return (get_diag_attacks(diag_values)) 
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Listing 4: Generalized Rank and File Attack Lookup Table 



"I 


def 


opt rnnlr n 1 1 n r t s ( } ' 
l _1 atlI\_aLLaLAd V/" 




2 




$ these aire the ira.nk sc^usire values 




3 




rank values — [[al , b 1 ,cl ,dl ,g1 , f 1 , 


el h 1 1 


4 




[a2,b2,c2,d2,e2,f2 , 


g2,h2] , 


5 




[a3 ,b3 ,c3 , d3 ,e3 , f 3 , 


g3,h3], 


6 




[ a4 , b4 , c4 , d4 , e4 , f 4 , 


g4,h4] , 


7 




[a5 ,b5 ,c5 , d5 ,e5 , f 5 , 


g5 , h5 ] , 


8 




[a6,b6,c6,d6,e6,f6 , 


g6,h6] , 


9 




[ a7 , b7 , c7 , d7 , e7 , f 7 , 


g7,h7] , 


10 




[a8 ,b8 ,c8 , d8 ,e8 , f 8 , 


g 8,h8]] 


11 




return (get.attacks (rank.values )) 




12 








13 


def 


get_file_attacks (): 




14 




# these are the file square values 




15 




file .values = [ [ al , a2 , a3 , a4 , a5 , a6 , a7 , a8 ] , 


16 




[bl ,b2,b3,b4,b5,b6, 


b7,b8] , 


17 




[ c 1 , c2 , c3 , c4 , c5 , c6 , 


c7 ,c8] , 


18 




[dl ,d2,d3,d4,d5,d6, 


d7,d8] , 


19 




[ el , e2 , e3 , e4 , e5 , e6 , 


e7,e8] , 


20 




[fl ,f2 ,f3 ,f4 ,f5 ,f6 , 


f7 , f 8 ] , 


21 




[gl ,g2 ,g3 ,g4 , g5 ,g6 , 


g7,g8], 


22 




[hi ,h2 ,h3 ,h4 , h5 ,h6 ,h7 ,h8]] 


23 




return (get. attacks(file. values)) 





This algorithm is general enough to allow for the rank and file attack tables to be generated and these are refor- 
mulated to work with this approach and the listings are shown in Listing 4. 



3. EXPERIMENTAL RESULTS 



OS and CPU 


Rotated Bitboards Time (s) 


Direct Lookup Time (s) 


OS X 10.4.9 2.33 GHz Intel Core 2 Duo 


7.29 


6.42 


Linux 2.6.9 3.4 GHz Intel Quad Xeon 


8.82 


7.67 


OS X 10.4.9 1.67 GHz PowerPC G4 


16.31 


14.13 


SunOS 5.8 1.5 GHz dual UltraSPARC-ffli 


23.95 


19.06 


FreeBSD 6.2 500 MHz Pentium 3 


58.17 


44.85 



Table 1: Move Generation Results for Rotated Bitboards and Direct Lookup. 



A performance comparison of simple move generation was made between a rotated bitboard implementation and 
a direct lookup implementation. The test results are shown in Table 1 . The times shown reflect a comparison 
of the move generation routines. A well known and well studied set of test cases exists in the Encyclopedia of 
Chess Middle Games (ECM). Positions were selected from the ECM (Krogius, 1980) and for each of the 879 
test positions, a list of the main board position as well as three rotated boards were precalculated and saved in a 
list used by both methods. The moves were then generated for each of these 879 positions using the same list of 
bitboards generated earlier. The move generation functions for direct lookup and those for the rotated bitboards 
differed only in how they handled the sliding piece attacks. This process was repeated 10 times for each of the 
two types of approaches. In generating moves for rotated bitboards, we required additional shifting and masking 
operations before the lookup of the attacks could take place. Furthermore, the overhead of maintaining and 
updating the rotated bitboards is not accounted for since these test positions represent games in mid play where 
the rotated bitboards were precalculated. 

The results shown indicate that directly looking up the attacking moves for sliding pieces in hash tables improves 
the move generation speeds from 10% to 15% depending on computer architecture. Further efficiencies can 
be expected in a full implementation where the overhead of maintaining rotated bitboards is eliminated. The 
implementation and test code is made available in an Open-Source, interactive, chess programming module 
called "Shatranj" (Tannous, 2006). 
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4. CONCLUSIONS AND FUTURE WORK 

We have described an approach for obtaining direct access to the attacked squares of sliding pieces without resort- 
ing to rotated bitboards. Detailed algorithms and working code illustrate how the four hash tables were derived. 
The attacked squares are directly retrieved from the hash tables once the occupancy for the particular rank, file 
or diagonal was retrieved by the appropriate masks. Using these four hash tables, maintaining incrementally 
updated rotated bitboards becomes unnecessary as does the required shifting and masking required to obtain the 
consecutive occupancy bits for a rank, file or diagonal. In addition to simplifying the implementation, we can 
expect a performance improvement in move generation of at least 10%. Taking the implementation a bit further, 
the hash tables described in this paper are also useful for implementing evaluation functions which include piece 
mobilty and attack threats. When the additional impact of complex evaluation functions is taken into account, the 
speed improvements should be greater then the results presented here. 

Since most chess implementations do not use a high level interpreted language such as Python, it is difficult to 
estimate the effect of cache loading and execution speed. The results presented here only reflect the savings seen 
by move generation and not those of a fully implemented chess engine. Further research is needed to quantify 
the effect of these changes on cache utilization in a complete chess engine. 

Alternatives to rotated bitboards have gained some popularity recently. Minimal perfect hash functions as de- 
scibed in (Czech, Havas, and Majewski, 1992) have been used to create hash tables where the index is calculated 
based on the mover square and occupancy bitboard. A recent refinement of this described in (Leiserson, Prokop, 
and Randall, 1998), called magic move generation, further reduces the memory requirements of the hash table. 
In this approach, a "magic multiplier" for a particular square is multiplied by an occupancy bitboard and then 
shifted by another "magic" number. This provides a hash index where the attacked squares can be retrieved 
from a hash table. Performance comparisons of the built in hash tables provided by interpreted languages and 
techniques involving manually creating minimal perfect hash functions as well as hash functions using de Bruijn 
sequences (a.k.a. magic move generation techniques) could also be explored in future work. Representation of 
chess knowledge with the data structures provided by high level languages seems to have received very little 
attention since the primary focus of the majority of work has been improving execution speed, an area that places 
interpreted languages at a distinct disadvantage. 
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